The continued growth of digital communication has created an increasing need to make such communications secure and verifiable. One way to achieve these goals is through the use of a security key infrastructure (SKI). An SKI is a set of services enabling the use and management of a key based security system providing the underlying technology for authentication, privacy and non-repudiation of digital communications.
In an SKI based security system, every relevant entity (e.g. user, organization, network node) is assigned a unique secret key (typically a very large random number). The key is considered to be the xe2x80x9ccredentialsxe2x80x9d of the entity to which it is assigned, and an entity can prove its identity by proving that it xe2x80x9cpossessesxe2x80x9d its secret key. This can be done, for example, by performing certain mathematical functions on digital documents using the secret key to produce a so-called xe2x80x9cdigital signature,xe2x80x9d which can be used both to authenticate the source of the document, and to prevent the entity which xe2x80x9csignedxe2x80x9d it from repudiating its signature later on.
An SKI can be used to establish a temporary secure and trusted connection (a xe2x80x9csessionxe2x80x9d) between a client and a server as follows. The client uses procedures in the SKI to generate a xe2x80x9csession tokenxe2x80x9d which is mathematically related to the secret key of the client (or of the user working on the client), and which also includes an encrypted xe2x80x9csession key.xe2x80x9d The session token is then sent to the server, along with a request to establish a secure connection. The server uses procedures in the SKI which can test whether the session token has the appropriate mathematical relationship to the secret key of the putative sender of the request, thus enabling the server to test the authenticity of the request. The client may also use procedures in the SKI to extract the session key from the session token. Since the session key is known only to the client and the server, it can be used as an encryption key to establish an encrypted communication channel between the client and the server.
Examples of SKIs include so-called symmetrical key infrastructures, such as the Kerberos system, described in the document RFC1510 available from the Internet Engineering Task Force, and so-called public key infrastructures (PKIs) such as Entrust/PKI, available from Entrust, Inc., and described at http://www.entrust.com/entrust/index.htm, and OnSite, available from Verisign, Inc. and described as http://www.verisign.com.
A PKI is an SKI that utilizes public key cryptography, in which entities are assigned two keys, one public and one private. The two keys have a mathematical relationship such that data encrypted by one key can only be decrypted using the other key, and vice versa. An entity can therefore encrypt information using its private key, and send it to a recipient who can decrypt it using the entity""s public key. This permits the recipient to authenticate the identity of the sender without ever having to learn its private key, so long as the recipient can be assured of the sender""s public key. Conversely, information can be encrypted with an entity""s public key, thus providing way of securing the data so that only the entity possessing the private key will be able to decrypt it.
One of the features of a PKI is that it provides a trusted third party or certificate authority (CA), which is a trusted source of information about public keys. A certificate authority issues digital xe2x80x9ccertificatesxe2x80x9d which attest to the assignment of a particular public key to a particular entity. The certificate is cryptographically xe2x80x9csignedxe2x80x9d by the CA, and this signature can be verified using the CA""s public key. Thus, as long as the CA itself is trusted, recipients may rely on such certificates to authenticate sources of information.
For an organization to implement a PKI, it must either create an internal CA, or rely on a third party to provide one. Toolkits and products for creating CAs are available from vendors such as Entrust, Netscape, Microsoft and Xcert. Third party CA services are provided by vendors such as Verisign, GTE Cybertrust and CertCo.
One impediment to the widespread implementation of SKI systems is the problem of application support. SKI services are typically not accessed by users directly, but are instead called from within an application via an application programming interface (API). However an application can access an SKI only if it has been programmed to utilize the SKI""s API. Because many legacy applications and applications on the market today have not been programmed for use with an SKI, an organization seeking to utilize an SKI system would need to spend considerable time and effort retrofitting existing systems to take advantage of SKI services.
An additional problem arises because there is no standard API which is provided by all of the various SKI systems available today. As a result, software vendors that do incorporate the ability to use an SKI in their products typically provide compatibility with only one SKI API, thus limiting customers in the choice of SKIs they may wish to employ.
The difficulty in employing an SKI in an existing networked computing environment may be better understood by reference to FIGS. 1-6.
Shown in FIG. 1 is a network computer system 100 having a network 110 that connects clients 120 and servers 130. Clients 120 include any device capable of receiving information from a user and transmitting digital data over network 110, including networked computer workstations, automatic teller machines, cable television receivers, PCS devices, and the like. Data servers include any device responsive to data requests received over network 110, including network file system file servers, internet web servers, database servers, and the like. Users therefore use clients 120 to access data or services provided by servers 130.
FIG. 2 is a schematic diagram of a client 120 and a server 130 connected to a network 110. A client 120 includes an input device 140, capable of receiving information from a user, and an output device 150, capable of providing information to a user. Client 120 contains client programs 160 which receive inputs from a user via the input device 140, and provide outputs to the user via output device 150. Client programs 160 communicate over network 110 with server programs 170 located on servers 130, which provide data or services in response to requests received from client programs 160. By using a client program 160 located on client 120, a user may therefore access data or services located on a server 130.
Client programs 160 and server programs 170 will be referred to collectively as xe2x80x9capplication programs.xe2x80x9d Referring now to FIG. 3, an application program 175 typically does not have the ability to access network hardware directly. Rather, they access the network 110 by using network access module (NAM) 180 provided by an operating system. The network access module 180 provides a network application program interface (network API) 190 that is recognized by each client program 160. For example, in a MICROSOFT WINDOWS 95((trademark)) environment, application programs typically access a network through the Winsock network access module, which is provided as a dynamic load library (DLL) by the WINDOWS 95 operating system.
Client programs 160 are of two types, security extensible 200, and security non-extensible 210. Referring now to FIG. 4, security extensible client programs 200 may have a built-in security module 220, as in client programs 200a and 200b, which provides built-in security services for the client program. For example, the built-in security module 220 may provide authentication services by requiring a user to enter a password which can be checked against a password file maintained by the client program.
A security extensible client program 200 accesses its built-in security module 220 using a security services application program interface (security services API) 230, .such as the Generic Security Services API (GSS-API), described in the publication RFC2078 available from the Internet Engineering Task Force, the Common Data Security Architecture (CDSA), developed by Intel Corp. and described at www.intel.com/ial/security and www.opengroup.org/publications/catalog/c707.htm, or the Cryptographic Application Programming Interface (CAPI), described at www.microsoft.com/security/tech/cryptoapi. The security features of a program using a security services API are therefore extensible: built-in security module 220 can be replaced with an extension module that provides improved or extended security features using the same security services API 230.
Alternatively, a security extensible client program 200 may have no built-in security features, but may nonetheless be capable of requesting security services through a given security services API 230, as illustrated by client programs 200c and 200d. Such a program is able to provide security services if an appropriate extension module is linked to it.
The security services APIs 230 recognized by security extensible client programs 200 are not necessarily the same, as illustrated by the differing shapes used to represent security services APIs in FIG. 4.
Referring now to FIG. 5, a security non-extensible client program 210 may or may not provide built-in security features 215, however it is not extensible to provide additional security features because it does not recognize a security services API 230.
Like client programs 160, server programs 170 may be security extensible or security non-extensible.
FIG. 6 shows schematically a set of SKIs 260. Each SKI 260 includes a security services API 230, and a set of SKI services 270 that can be accessed through it. The security services APIs 230 provided by the SKIs 260 are not necessarily the same.
A system manager who wished to integrate one or more of the SKIs 260 shown in FIG. 6 with, for example, the client programs illustrated in FIGS. 4 and 5 would be faced with two difficulties. First, the system might include security extensible client programs 200 or security extensible server programs 240 that did not recognize the same security services API 230. In such a case, the system manager would have to install multiple SKIs 260 in order to provide SKI services 270 for all of the security extensible client programs 200 and server programs 240 on the system, and would not have the flexibility to use an SKI, such as SKI 260c in FIG. 6, having an API not recognized by any of the programs.
In addition, in the case of security non-extensible client programs 210 (or security non-extensible server programs), the system manager would not be able to link such programs to an SKI 260 without modifying the program itself, which could be quite time consuming and, where source code was not available, impractical.
The present invention provides a system and method for enabling security key infrastructure (SKI) resources to be easily integrated into a network computer system. The present invention further provides a system and method for providing secure and tamper-evident tracking of SKI service requests on a network computer system. The present invention further provides a system and method for authorizing user access to system resources on network computer system. The present invention further provides a system and method for integrating application programs lacking a security services API into a security framework utilizing SKI services.
In a first aspect, the invention provides a method for integrating a security key infrastructure. A security key infrastructure service request is transmitted from a first application program to a security integration module. In the security integration module, a first policy from a policy server is requested. In the security integration module, a first security key infrastructure is selected to service the security key infrastructure service request, according to the first policy. The security key infrastructure service request is transmitted from the security integration module to the selected first security key infrastructure.
In another aspect, the invention provides a method for securing a distributed data processing system having a client program on a client having a user, and a server program on a server connected to the client by a network, including, in the client, intercepting a request by the client program to open a network connection to a server program, determining whether the user is authorized to open the connection by reference to a policy associated with the user, sending a message requesting to the server to establish a network connection, only if the user is authorized by the policy to establish the connection.
In another aspect, the invention provides a method for auditing a security key infrastructure transaction including transmitting a security key infrastructure transaction request from an application program to a security integration modules the security integration module, selecting an appropriate security key infrastructure to perform the requested transaction, transmitting the request from the security integration module to the selected security key infrastructure, and storing in an audit log audit data related to the request.